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Protocol Support for High Availability of IKEv2/IPsec 
Abstract 


The IPsec protocol suite is widely used for business-critical network 
traffic. In order to make IPsec deployments highly available, more 
scalable, and failure-resistant, they are often implemented as IPsec 
High Availability (HA) clusters. However, there are many issues in 
IPsec HA clustering, and in particular in Internet Key Exchange 
Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec 
Cluster Problem Statement", enumerates the issues encountered in the 
IKEv2/IPsec HA cluster environment. This document resolves these 
issues with the least possible change to the protocol. 


This document defines an extension to the IKEv2 protocol to solve the 
main issues of "IPsec Cluster Problem Statement" in the commonly 
deployed hot standby cluster, and provides implementation advice for 
other issues. The main issues solved are the synchronization of 
IKEv2 Message ID counters, and of IPsec replay counters. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6311. 
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1. Introduction 


The IPsec protocol suite, including the Internet Key Exchange 
Protocol version 2 (IKEv2), is a major building block of virtual 
private networks (VPNs). In order to make such VPNs highly 
available, more scalable, and failure-resistant, these VPNs are 
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34.le large: Amount Gf. State loge y ees vx eye. 
3.2. Multiple Members Using the Same SA ................... e... 
3.3. Avoiding Collisions in SPI Number Allocation ............. 
3.4. Interaction with Counter Modes .................. eee 
4. The IKEv2/IPsec SA Counter Synchronization Problem ............ 
5. SA Counter Synchronization Solution .4.-...4 sse sese Rd eres 
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implemented as IKEv2/IPsec Highly Available (HA) clusters. However, 
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there are many issues with the IKEv2/IPsec HA cluster. Sections 3 
and 4 below expand on the issues around the IKEv2/IPsec HA cluster 
solution, issues which were first described in the problem 
statement [6]. 


In the case of a hot standby cluster implementation of IKEv2/ 
IPsec-based VPNs, the IKEv2/IPsec session is first established 
between the peer and the active member of the cluster. Later, the 
active member continuously syncs/updates the IKE/IPsec security 
association (SA) state to the standby member of the cluster. This 
primary SA state sync-up takes place upon each SA bring-up and/or 
rekey. Performing the SA state synchronization/update for every 
Single IKE and IPsec message is very costly, so normally it is done 
periodically. As a result, when the failover event happens, this is 
first detected by the standby member and, possibly after a 
considerable amount of time, it becomes the active member. During 
this failover process, the peer is unaware of the failover event, and 
keeps sending IKE requests and IPsec packets to the cluster, as in 
fact it is allowed to do because of the IKEv2 windowing feature. 
After the newly active member starts, it detects the mismatch in IKE 
Message ID values and IPsec replay counters and needs to resolve this 
situation. Please see Section 4 for more details of the problem. 


This document defines an extension to the IKEv2 protocol to solve the 
main issues of IKE Message ID synchronization and IPsec SA replay 
counter synchronization, and gives implementation advice to address 
other issues. Following is a summary of the solutions provided in 
this document: 


o IKEv2 Message ID synchronization: This is done by syncing up the 
expected send and receive Message ID values with the peer, and 
updating the values at the newly active cluster member. 


o IPsec replay counter synchronization: This is done by incrementing 
the cluster's outgoing SA replay counter values by a "large" 
number; in addition, the newly active member requests the peer to 
increment the replay counter values it is using for the peer's 
outgoing traffic. 


Although this document describes the IKEv2 Message ID and IPsec 
replay counter synchronization in the context of an IPsec HA cluster, 
the solution provided is generic and can be used in other scenarios 
where IKEv2 Message ID or IPsec SA replay counter synchronization may 
be required. 
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Implementations differ on the need to synchronize the IKEv2 Message 
ID and/or IPsec replay counters. Both of these problems are handled 
separately, using a separate notification for each capability. This 
provides the flexibility of implementing either or both of these 
solutions. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [1]. 


"SA Counter Synchronization" is the informational exchange defined in 
this document to synchronize the IKEv2/IPsec SA counter information 
between one member of the cluster and the peer. 


Some of the terms listed below are reused from [6] with further 
clarification in the context of the current document. 


o "Hot Standby Cluster", or "HS Cluster", is a cluster where only 
one of the members is active at any one time. This member is also 
referred to as the "active" member, whereas the other(s) are 
referred to as "standby" members. The Virtual Router Redundancy 
Protocol (VRRP) [7] is one method of building such a cluster. The 
goal of the hot standby cluster is to create the illusion of a 
single virtual gateway to the peer(s). 


o "Active Member" is the primary member in the hot standby cluster. 
It is responsible for forwarding packets on behalf of the virtual 


gateway. 

o "Standby Member" is the primary backup member. This member takes 
control, i.e., becomes the active member, after the failover 
event. 


o "Peer" is an IKEv2/IPsec endpoint that maintains an IPsec 
connection with the hot standby cluster. The peer identifies the 
cluster by the cluster's (single) IP address. If a failover event 
occurs, the standby member of the cluster becomes active, and the 
peer normally doesn't notice that failover has taken place. 
Although we treat the peer as a single entity, it may also be a 
cluster. 
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o "Multiple failover" is the situation where, in a cluster with 
three or more members, multiple failover events happen in rapid 
succession, e.g., from M1 to M2, and then to M3. It is our goal 
that the implementation should be able to handle this situation, 
i.e., to handle the new failover event even if it is still 
processing the old failover. 


o "Simultaneous failover" is the situation where two clusters have 
an IPsec connection between them, and failover happens at both 
ends at the same time. It is our goal that implementations should 


be able to handle simultaneous failover. 


o "IPsec replay counter" is the Encapsulating Security Payload (ESP) 
Sequence Number or Extended Sequence Number (Section 2.2 of [2]), 
or the respective field in the Authentication Header (AH) protocol 
(Section 2.5 of [3]). 


The generic term "IKEv2/IPsec SA Counters" is used throughout this 
document. This term refers to both IKEv2 Message ID counters and 
IPsec replay counters. According to the IPsec standards, the IKEv2 
Message ID counter is mandatory, and used to ensure reliable delivery 
as well as to protect against message replay in IKEv2; the IPsec SA 
replay counters are optional, and are used to provide the IPsec anti- 
replay feature. 
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Some of these terms are used in the following architectural diagram. 
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An IPsec Hot Standby Cluster 
3. Issues Resolved from IPsec Cluster Problem Statement 
"IPsec Cluster Problem Statement" [6] enumerates the problems raised 


by IPsec clusters. The following table lists the problem statement's 
sections that are resolved by this document. 
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o 3.7. Simultaneous Use of IKE and IPsec SAs by Different Members 
* 3.7.1. Outbound SAs Using Counter Modes 

o 3.8. Different IP Addresses for IKE and IPsec 

o 3.9. Allocation of SPIs 


The main problem areas are solved using the protocol extension 
defined below, starting with Section 5; additionally, this section 
provides implementation advice for other issues in the following 
subsections. Implementers should note that these subsections include 
a number of new security-critical requirements. 


3.1. Large Amount of State 


Section 3.2 of the problem statement [6] mentions that a lot of state 
needs to be synchronized for a cluster to be transparent. The actual 
volume of that data is very much implementation-dependent, and even 
for the same implementation, the amounts of data may vary wildly. An 
IPsec gateway used for inter-domain VPN with a dozen other gateways, 
and having SAs that are rekeyed every 8 hours, will need a lot less 
synchronization traffic than a similar gateway used for remote 
access, and supporting 10,000 clients. This is because counter 
synchronization is proportional to the number of SAs and requires 
little data, and the setting up of an SA requires a lot of data. 
Additionally, remote access IKE and IPsec SA setup tend to happen at 
a particular time of day, so the example gateway with the 10,000 
clients may see 30-50 IKE SA setups per second at 9:00 AM. This 
would require very heavy synchronization traffic over that short 
period of time. 


If a large volume of traffic is necessary, it may be advisable to use 
a dedicated high-speed network interface for synch traffic. When 
packet loss can be made extremely low, it may be advisable to use a 
stateless transport such as UDP, to minimize network overhead. 


If these methods are insufficient, it may be prudent that for some 
SAs the entire state is not synchronized. Instead, only an 
indication of the SA’s existence is synchronized. This, in 
combination with a sticky solution (as described in Section 3.7 of 
the problem statement [6]) ensures that the traffic from a particular 
peer does not reach a different member before an actual failover 
happens. When that happens, the method described in [8] can be used 
to quickly force the peer to set up a new SA. 
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3.2. Multiple Members Using the Same SA 


In a load-sharing cluster of the "duplicate" variety (see Section 3.7 
of the problem statement [6]), multiple members may need to send 
traffic with the same selectors. To actually use the same SA, the 
cluster would have to synchronize the replay counter after every 
packet, and that would impose unreasonable requirements on the synch 
connection. 


A far better solution would be to not synchronize the outbound SA, 
and create multiple outbound SAs, one for each member. The problem 
with this option is that the peer might view these multiple parallel 
SAs as redundant, and tear down all but one of them. 


Section 2.8 of [4] specifically allows multiple parallel SAs, but the 
reason given for this is to have multiple SAs with different Quality 
of Service (QoS) attributes. So while this is not a new requirement 
of IKEv2 implementations working with QoS, we re-iterate here that 
IPsec peers MUST accept the long-term existence of multiple parallel 
SAs, even when QoS mechanisms are not in use. 


3.3. Avoiding Collisions in SPI Number Allocation 


Section 3.9 of the problem statement [6] describes the problem of two 
cluster members allocating the same Security Parameter Index (SPI) 
number for two different SAs. This behavior would violate 

Section 4.4.2.1 of [5]. There are several schemes to allow 
implementations to avoid such collisions, such as partitioning the 
SPI space, a request-response over the synch channel, and locking 
mechanisms. We believe that these are sufficiently robust and 
available so that we don't need to make an exception to the rules in 
Section 4.4.2.1 of RFC 4301 [5], and we can leave this problem for 
the implementations to solve. Cluster members must not generate 
multiple inbound SAs with the same SPI. 


3.4. Interaction with Counter Modes 


For SAs involving counter mode ciphers such as Counter Mode (CTR) [9] 
or Galois/Counter Mode (GCM) [10], there is yet another complication. 
The initial vector for such modes MUST NOT be repeated, and senders 
may use methods such as counters or linear feedback shift registers 
(LFSRs) to ensure this property. For an SA shared between multiple 
active members (load-sharing cases), implementations MUST ensure that 
no initial vector is ever repeated. Similar concerns apply to an SA 
failing over from one member to another. See [11] for a discussion 
of this problem in another context. 
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Just as in the SPI collision problem, there are ways to avoid a 
collision of initial vectors, and this is left up to implementations. 
In the context of load sharing, parallel SAs are a simple solution to 
this problem as well. 


4. The IKEv2/IPsec SA Counter Synchronization Problem 


The IKEv2 protocol [4] states that "An IKE endpoint MUST NOT exceed 
the peer's stated window size for transmitted IKE requests". 


All IKEv2 messages are required to follow a request-response 
paradigm. The initiator of an IKEv2 request MUST retransmit the 
request, until it has received a response from the peer.  IKEv2 
introduces a windowing mechanism that allows multiple requests to be 
outstanding at a given point of time, but mandates that the sender's 
window should not move until the oldest message it has sent is 
acknowledged. Loss of even a single message leads to repeated 
retransmissions followed by an IKEv2 SA teardown if the 
retransmissions remain unacknowledged. 


An IPsec hot standby cluster is required to ensure that in the case 
of failover, the standby member becomes active immediately. The 
standby member is expected to have the exact value of the Message ID 
counter as the active member had before failover. Even assuming the 
best effort to update the Message ID values from active to standby 
member, the values at the standby member can still be stale due to 
the following reasons: 


o The standby member is unaware of the last message that was 
received and acknowledged by the previously active member, as the 
failover event could have happened before the standby member could 
be updated. 


o The standby member does not have information about on-going 
unacknowledged requests sent by the previously active member. As 
a result, after the failover event, the newly active member cannot 
retransmit those requests. 


When a standby member takes over as the active member, it can only 
initialize the Message ID values from the previously updated values. 
This would make it reject requests from the peer when these values 
are stale. Conversely, the standby member may end up reusing a stale 
Message ID value, which would cause the peer to drop the request. 
Eventually, there is a high probability of the IKEv2 and 
corresponding IPsec SAs getting torn down simply because of a 
transitory Message ID mismatch and retransmission of requests, 
negating the benefits of the high-availability cluster despite the 
periodic update between the cluster members. 
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A similar issue is also observed with IPsec anti-replay counters if 
anti-replay protection is enabled, which is commonly the case. 
Regardless of how well the ESP and AH SA counters are synchronized 
from the active to the standby member, there is a chance that the 


standby member would end up with stale counter values. The standby 
member would then use those stale counter values when sending IPsec 
packets. The peer would drop such packets, since when the anti- 


replay protection feature is enabled, duplicate use of counters is 
not allowed. Note that IPsec allows the sender to skip some counter 
values and continue sending with higher counter values. 


We conclude that a mechanism is required to ensure that the standby 
member has correct Message ID and IPsec counter values when it 
becomes active, so that sessions are not torn down as a result of 
mismatched counters. 


5. SA Counter Synchronization Solution 


This document defines two separate approaches to resolving the issues 
of mismatched IKE Message ID values and IPsec counter values. 


o In the case of IKE Message ID values, the newly active cluster 
member and the peer negotiate a pair of new values so that future 
IKE messages will not be dropped. 


o For IPsec counter values, the newly active member and the peer 
both increment their respective counter values, "skipping forward" 
by a large number, to ensure that no IPsec counters are ever 
reused. 


Although conceptually separate, the two synchronization processes 
would typically take place simultaneously. 


First, the peer and the active member of the cluster negotiate their 
ability to support IKEv2 Message ID synchronization and/or IPsec 
replay counter synchronization. This is done by exchanging one or 
both of the IKEV2 MESSAGE ID SYNC SUPPORTED and 

IPSEC REPLAY COUNTER SYNC SUPPORTED notifications during the IKE AUTH 
exchange. When negotiating these capabilities, the responder MUST 
NOT assert support of a capability unless such support was asserted 
by the initiator. Only a capability whose support was asserted by 
both parties can be used during the lifetime of the SA. The peer's 
capabilities with regard to this extension are part of the IKEv2 SA 
state, and thus MUST be shared between the cluster members. 


This per-IKE SA information is shared with the other cluster members. 
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Peer Active Member 
HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH, 

[N(IKEV2 MESSAGE ID SYNC SUPPORTED),] 

[N(IPSEC REPLAY COUNTER SYNC SUPPORTED),] 

SAi2, TSi, TSr) ---------- > 


See ee HDR, SK (IDr, [CERT+], [CERTREQ+], AUTH, 
[N(IKEV2. MESSAGE, ID SYNC. SUPPORTED), ] 
[N(IPSEC REPLAY COUNTER SYNC. SUPPORTED),] 
SAr2, TSi, TSr} 


After a failover event, the standby member MAY use the IKE Message ID 
and/or IPsec replay counter synchronization capability when it 
becomes the active member, and provided support for the capabilities 
used has been negotiated. Following that, the peer MUST respond to 
any synchronization message it receives from the newly active cluster 
member, subject to the rules noted below. 


After the failover event, when the standby member becomes active, it 
has to synchronize its SA counters with the peer. There are now four 
possible cases: 


1. The cluster member wishes to only perform IKE Message ID value 
synchronization. In this case, it initiates an Informational 
exchange, with Message ID zero and the sole notification 
IKEV2 MESSAGE ID SYNC. 


2. If the newly active member wishes to perform only IPsec replay 
counter synchronization, it generates a regular IKEv2 
Informational exchange using the current Message ID values, and 
containing the IPSEC REPLAY COUNTER SYNC notification. 


3. If synchronization of both counters is needed, the cluster member 
generates a zero-Message ID message as in case 41, and includes 
both notifications in this message. 


4. Lastly, the peer may not support this extension. This is known 
to the newly active member (because the cluster members must 
share this information, as noted earlier). This case is the 


existing IKEv2 behavior, and the IKE and IPsec SAs may or may not 
survive the failover, depending on the exact state on the peer 
and the cluster member. 


This figure contains the IKE message exchange used for SA counter 


synchronization. The following subsections describe the details of 
the sender and receiver processing of each message. 
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Standby [Newly Active] Member Peer 


HDR, SK {N(IKEV2_MESSAGE_ID_SYNC), 
[N(IPSEC REPLAY COUNTER SYNC)]] -------- > 


ULL HDR, SK (N(IKEV2 MESSAGE ID SYNC)) 
Alternatively, if only IPsec replay counter synchronization is 


desired, a normal Informational exchange is used, where the Message 
ID is non-zero: 


Standby [Newly Active] Member Peer 
HDR, SK(N(IPSEC REPLAY COUNTER SYNC)] --------> ^0. 
«--------- HDR 
5.1. Processing Rules for IKE Message ID Synchronization 


The newly active member sends a request containing two counter 
values, one for the member (itself) and another for the peer, as well 
as a random nonce. We denote the values Ml and Pl. The peer 
responds with a message containing two counter values, M2 and P2 
(note that the values appear in the opposite order in the 
notification's payload). The goal of the rules below is to prevent 
an attacker from replaying a synchronization message and thereby 
invalidating IKE messages that are currently in process. 


o Ml is the next sender's Message ID to be used by the member. M1 
MUST be chosen so that it is larger than any value known to have 
been used. It is RECOMMENDED to increment the known value at 
least by the size of the IKE sender window. 


o P1 SHOULD be 1 more than the last Message ID value received from 
the peer, but may be any higher value. 


o The member SHOULD communicate the sent values to the other cluster 
members, so that if a second failover event takes place, the 
synchronization message is not replayed. Such a replay would 
result in the eventual deletion of the IKE SA (see below). 


o The peer MUST silently drop any received synchronization message 
if M1 is lower than or equal to the highest value it has seen from 
the cluster. This includes any previous received synchronization 
messages. 
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o M2 MUST be at least the higher of the received M1, and one more 
than the highest sender value received from the cluster. This 
includes any previous received synchronization messages. 


o P2 MUST be the higher of the received P1 value, and one more than 
the highest sender value used by the peer. 


o The request contains a Nonce field. This field MUST be returned 
in the response, unchanged. A response MUST be silently dropped 
if the received nonce does not match the one that was sent. 


o Both the request and the response MUST NOT contain any additional 
payloads, other than an optional IPSEC REPLAY COUNTER SYNC 
notification in the request. 


o The request and the response MUST both be sent with a Message ID 
value of zero. 


5.2. Processing Rules for IPsec Replay Counter Synchronization 


Upon failover, the newly active member MUST increment its own replay 
counter (the counter used for outgoing traffic), so as to prevent the 
case of its traffic being dropped by the peer as replay. We note 
that IPsec allows the replay counter to skip forward by any amount. 
The estimate is based on the outgoing IPsec bandwidth and the 
frequency of synchronization between cluster members. In those 
implementations where it is difficult to estimate this value, the 
counter can be incremented by a very large number, e.g., 2**30. In 
the latter case, a rekey SHOULD follow shortly afterwards, to ensure 
that the counter never wraps around. 


Next, the cluster member estimates the number of incoming messages it 
might have missed, using similar logic. The member sends out an 
IPSEC REPLAY COUNTER SYNC notification, either stand-alone or 
together with an IKEV2 MESSAGE ID SYNC notification. 


If the IPSEC REPLAY COUNTER SYNC is included in the same message as 
IKEV2 MESSAGE ID SYNC, the peer MUST process the Message ID 
notification first (which might cause the entire message to be 
dropped as a replay). Then, it MUST increment the replay counters 
for all Child SAs associated with the current IKE SA by the amount 
requested by the cluster member. 


6. IKEv2/IPsec Synchronization Notification Payloads 


This section lists the new notification payload types defined by this 
extension. 
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All multi-octet fields representing integers are laid out in big 
endian order (also known as "most significant byte first", or 
"network byte order"). 


6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification 


This notification payload is included in the IKE_AUTH request/ 
response to indicate support of the IKEv2 Message ID synchronization 
mechanism described in this document. 


1 2 3 
0. d. 2:39:45, 96 B29" 0:1 Be 3). 4. 5 6 BO. Ou D2: 39 4 5 6 7.8.9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Next Payload |c] RESERVED | Payload Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Protocol ID (=0) | SPI Size (=0) | Notify Message Type 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The ’Next Payload’, 'Payload Length’, 'Protocol ID’, 'SPI Size’, and 
"Notify Message Type’ fields are the same as described in Section 3 
of [4]. The 'SPI Size’ field MUST be set to 0 to indicate that the 
SPI is not present in this message. The 'Protocol ID' MUST be set to 
0, since the notification is not specific to a particular security 
association. The 'Payload Length' field is set to the length in 
octets of the entire payload, including the generic payload header. 
The 'Notify Message Type’ field is set to indicate 

IKEV2 MESSAGE ID SYNC SUPPORTED (16420). There is no data associated 
with this notification. 


6.2. The IPSEC REPLAY COUNTER SYNC SUPPORTED Notification 


This notification payload is included in the IKE AUTH request/ 
response to indicate support for the IPsec SA replay counter 
synchronization mechanism described in this document. 


1 2 3 
0:1 2.94.5756 7.8.9.0 T 2-3 4-5.6 7:8 90.1 2.3.4 5» 6 7-8 9-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Next Payload lel RESERVED | Payload Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Protocol ID (=0) | SPI Size (=0) | Notify Message Type 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


The ’Next Payload’, 'Payload Length’, 'Protocol ID’, 'SPI Size’, and 
‘Notify Message Type’ fields are the same as described in Section 3 
of [4] . The ’SPI Size’ field MUST be set to 0 to indicate that the 
SPI is not present in this message. The 'Protocol ID' MUST be set to 
0, since the notification is not specific to a particular security 
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association. The 'Payload Length’ field is set to the length in 
octets of the entire payload, including the generic payload header. 
The 'Notify Message Type' field is set to indicate 

IPSEC REPLAY COUNTER SYNC SUPPORTED (16421). There is no data 
associated with this notification. 


6.3. The IKEV2 MESSAGE ID SYNC Notification 


This notification payload type (16422) is defined to synchronize the 
IKEv2 Message ID values between the newly active (formerly standby) 
cluster member and the peer. 


1 2 3 
0i 1,2 94 5.6- 5.8. 90.1 2.3.4 5. 6 7.8 9$); L:2.3 4 5-6 .7:8^9-«0.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Next Payload |c] RESERVED | Payload Length 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Protocol ID (=0) | SPI Size (=0) | Notify Message Type 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Nonce Data | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| EXPECTED SEND REQ MESSAGE ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+ 


EXPECTED_RECV_REQ_MESSAGE_ID | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


It contains the following data. 


o Nonce Data (4 octets): The random nonce data. The data should be 
identical in the synchronization request and response. 


o EXPECTED SEND REQ MESSAGE ID (4 octets): This field is used by the 
sender of this notification payload to indicate the Message ID it 
will use in the next request that it will send to the other 
protocol peer. 


o EXPECTED RECV REQ MESSAGE ID (4 octets): This field is used by the 
sender of this notification payload to indicate the Message ID it 
is expecting in the next request to be received from the other 
protocol peer. 


6.4. The IPSEC REPLAY COUNTER SYNC Notification 
This notification payload type (16423) is defined to synchronize the 


IPsec SA replay counters between the newly active (formerly standby) 
cluster member and the peer. Since there may be numerous IPsec SAs 
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established under a single IKE SA, we do not directly synchronize the 
value of each one. Instead, a delta value is sent, and all replay 
counters for Child SAs of this IKE SA are incremented by the same 
value. Note that this solution requires that either all Child SAs 
use Extended Sequence Numbers (ESNs) or else that no Child SA uses 
ESNs. This notification is only sent by the cluster. 


1 2 3 
01234567890123456789012345678<901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Next Payload |c] RESERVED | Payload Length 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Protocol ID (=0) | SPI Size (=0) | Notify Message Type 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Incoming IPsec SA delta value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The notification payload contains the following data. 


o Incoming IPsec SA delta value (4 or 8 octets): The sender requests 
that the peer should increment all the Child SA replay counters 
for the sender's incoming (the peer’s outgoing) traffic by this 
value. The size of this field depends on the ESN bit associated 
with the Child SAs: if the ESN bit is 1, the field’s size is 8 
octets; otherwise, it is 4 octets. We note that this constrains 
the Child SAs of each IKE SA to either all have the ESN bit on 
or off. 


7. Implementation Details 


This protocol does not change any of the existing IKEv2 rules 
regarding Message ID values. 


The standby member can initiate the synchronization of IKEv2 Message 
IDs under different circumstances. 


o When it receives a problematic IKEv2/IPsec packet, i.e., a packet 
outside its expected receive window. 


o When it has to send the first IKEv2/IPsec packet after a failover 
event. 


o When it has just received control from the active member and 


wishes to update the values proactively, so that it need not start 
this exchange later, when sending or receiving the request. 
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To clarify the first alternative: the normal IKE behavior of 
rejecting out-of-window messages is not changed, but such messages 
can still be a valid trigger for the exchange defined in this 
document. To avoid denial-of-service (DoS) attacks resulting from 
replayed messages, the peer MUST NOT initiate counter synchronization 
for any particular IKE SA more than once per failover event. 


The standby member can initiate the synchronization of IPsec SA 
replay counters: 


o If there has been traffic using the IPsec SA in the recent past 
and the standby member suspects that its replay counter may be 
stale. 


Since there can be a large number of sessions at the standby member, 
and sending synchronization exchanges for all of them may result in 
overload, the standby member can choose to initiate the exchange ina 
"lazy" fashion: only when it has to send or expects to receive 
traffic from each peer. In general, the standby member is free to 
initiate this exchange at its discretion. Implementation 
considerations include the ability to survive a certain amount of 
traffic loss, and the capacity of a cluster member to initiate 
counter synchronization simultaneously with a large number of peers. 


8. IKE SA and IPsec SA Message Sequencing 


The straightforward definitions of message sequence numbers, 
retransmissions, and replay protection in IPsec and IKEv2 are 
strained by the failover scenarios described in this document. This 
section describes some policy choices that need to be made by 
implementations in this setting. 


8.1. Handling of Pending IKE Messages 


After sending its "receive" counter, the cluster member MUST reject 
(silently drop) any incoming IKE messages that are outside its 
declared window. A similar rule applies to the peer. Local policies 
vary, and strict implementations will reject any incoming IKE message 
arriving before Message ID synchronization is complete. 


8.2. Handling of Pending IPsec Messages 
For IPsec, there is often a trade-off between security and 


reliability of the protected protocols. Here again, there is some 
leeway for local policy. Some implementations might accept incoming 
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traffic that is outside the replay window for some time after the 
failover event, and until the counters had been synchronized. Strict 
implementations will only accept traffic that’s inside the "safe" 
window. 


8.3. IKE SA Inconsistencies 


IKEv2 is normally a reliable protocol. As long as an IKE SA is 
valid, both peers share a single, consistent view of the IKE SA and 
all associated Child SAs. Failover situations as described in this 
document may involve forced deletion of IKE messages, resulting in 
inconsistencies, such as Child SAs that exist on only one of the 
peers. Such SAs might cause an INVALID_SPI to be returned when used 
by that peer. Note that Section 1.5 of [4] allows but does not 
mandate sending an INVALID_SPI notification in this case. 


The IPsecME Working Group discussed at some point a proposed set of 
rules for dealing with such situations. However, we believe that 
these situations should be rare in practice; as a result, the 
"default" behavior of tearing down the entire IKE SA is to be 
preferred over the complexity of dealing with a multitude of edge 
cases. 


9. Step-by-Step Details 


This section goes through the sequence of steps of a typical failover 
event, looking at a case where the IKEv2 Message ID values are 
synchronized. 


o The active cluster member and the peer device establish the 
session. They both announce the capability to synchronize counter 
information by sending the IKEV2 MESSAGE ID SYNC SUPPORTED 
notification in the IKE AUTH exchange. 


o Some time later, the active member dies, and a standby member 
takes over. The standby member sends its own idea of the IKE 
Message IDs (both incoming and outgoing) to the peer in an 
Informational message exchange with Message ID zero. 


o The peer first authenticates the message. The peer compares the 
received values with the values available locally and picks the 
higher value. It then updates its Message IDs with the higher 
values and also proposes the same values in its response. 


o The peer should not wait for any pending responses while 
responding with the new Message ID values. For example, if the 
window size is 5 and the peer's window is 3-7, and if the peer has 
sent requests 3, 4, 5, 6, and 7 and received responses only for 4, 
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Singh, 


5, 6, and 7 but not for 3, then it should include the value 8 in 
its EXPECTED_SEND_REQ MESSAGE ID payload and should not wait for a 
response to message 3 any more. 


Similarly, the peer should also not wait for pending (incoming) 
requests. For example, if the window size is 5 and the peer's 
window is 3-7, and if the peer has received requests 4, 5, 6, and 
7 but not 3, then it should send the value 8 in the 
EXPECTED RECV REQ MESSAGE ID payload, and should not expect to 
receive message 3 any more. 


Interaction with Other Specifications 


The usage scenario of this IKEv2/IPsec SA counter synchronization 
Solution is that an IKEv2 SA has been established between the active 
member of a hot standby cluster and a peer, followed by a failover 
event occurring and the standby member becoming active. The solution 
further assumes that the IKEv2 SA state was continuously synchronized 
between the active and standby members of the cluster before the 
failover event. 


o 


Session resumption [12] assumes that a peer (client or initiator) 
detects the need to re-establish the session. In IKEv2/IPsec SA 
counter synchronization, it is the newly active member (a gateway 
or responder) that detects the need to synchronize the SA counter 
after the failover event. Also, in a hot standby cluster, the 
peer establishes the IKEv2/IPsec session with a single IP address 
that represents the whole cluster, so the peer normally does not 
detect the event of failover in the cluster unless the standby 
member takes too long to become active and the IKEv2 SA times out 
by use of the IKEv2 liveness check mechanism. To conclude, 
session resumption and SA counter synchronization after failover 
are mutually exclusive: they are not expected to be used together, 
and both features can coexist within the same implementation 
without affecting each other. 


The IKEv2 Redirect mechanism for load balancing [13] can be used 
either during the initial stages of SA setup (the IKE SA INIT and 
IKE AUTH exchanges) or after session establishment. SA counter 
synchronization is only useful after the IKE SA has been 
established and a failover event has occurred. So, unlike 
Redirect, it is irrelevant during the first two exchanges. 


Redirect after the session has been established is mostly useful 
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for timed or planned shutdown/maintenance. A real failover event 
cannot be detected by the active member ahead of time, and so 
using Redirect after session establishment is not possible in the 


case of failover. So, Redirect and SA counter synchronization 
after failover are mutually exclusive, in the sense described 
above. 


o IKEv2 Failure Detection [8] solves a similar problem where the 
peer can rapidly detect that a cluster member has crashed based on 


a token. It is unrelated to the current scenario, because the 
goal in failover is for the peer not to notice that a failure has 
occurred. 


Security Considerations 


Since Message ID synchronization messages need to be sent with 
Message ID zero, they are potentially vulnerable to replay attacks. 
Because of the semantics of this protocol, these can only be denial- 
of-service (DoS) attacks, and we are aware of two variants. 


o Replay of Message ID synchronization request: This is countered by 
the requirement that the Send counter sent by the cluster member 
should always be monotonically increasing, a rule that the peer 
enforces by silently dropping messages that contradict it. 


o Replay of the Message ID synchronization response: This is 
countered by sending the nonce data along with the synchronization 
payload. The same nonce data has to be returned in the response. 
Thus, the standby member will accept a reply only for the current 
request. After it receives a valid response, it MUST NOT process 
the same response again and MUST discard any additional responses. 


As mentioned in Section 7, triggering counter synchronization by out- 
of-window, potentially replayed messages could open a DoS 
vulnerability. This risk is mitigated by the solution described in 
that section. 


IANA Considerations 
This document introduces four new IKEv2 Notification Message types as 


described in Section 6. The new Notify Message Types have been 
assigned values as follows. 
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4-----------------2-------------------- 4R------- + 
| Name | Value | 
4---------------2----2------------------ 4R------- + 
| IKEV2_MESSAGE_ID_SYNC_SUPPORTED | 16420 | 
| IPSEC REPLAY COUNTER SYNC SUPPORTED | 16421 | 
| IKEV2 MESSAGE ID SYNC | 16422 | 
| IPSEC REPLAY COUNTER SYNC | 16423 | 
4---------------2----2--------2---------- 4R------- * 
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Appendix A. IKEv2 Message ID Sync Examples 


This (non-normative) section presents some examples that illustrate 
how the IKEv2 Message ID values are synchronized. We use a tuple 
notation, denoting the two counters EXPECTED_SEND_REQ MESSAGE_ID and 
EXPECTED RECV REQ MESSAGE ID on each protocol party as 
(EXPECTED SEND REQ MESSAGE ID, EXPECTED RECV REQ MESSAGE ID). 


Note that if the IKE message counters are already synchronized (as in 
the first example), we expect the numbers to be reversed between the 

two sides. If one protocol party intends to send the next request as 
4, then the other expects the next received request to be 4. 


A.1. Normal Failover -- Example 1 
Standby (Newly Active) Member Peer 
Sync Request (0, 5) -------- > 


Peer has the values (5, 0), so it sends 
Keo Seas ssSS (5, 0) as the Sync Response 


In this example, the peer has most recently sent an IKE request with 
Message ID 4, and has never received a request. So the peer’s 
expected values for the next pair of messages are (5, 0). These are 
the same values as received from the member, and therefore they are 
sent as-is. 


A.2. Normal Failover -- Example 2 
Standby (Newly Active) Member Peer 
Sync Request (2, 3) -------- > 


Peer has the values (4, 5), so it sends 
&-—------------ (4, 5) as the Sync Response 


In this example, the peer has most recently sent an IKE message with 
the Message ID 3, and received one with ID 4. So the peer's expected 
values for the next pair of messages are (4, 5). These are both 
higher than the corresponding values just received from the member 
(the order of tuple members is reversed when doing this comparison!), 
and therefore they are sent as-is. 
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A.3. Normal Failover -- Example 3 
Standby (Newly Active) Member Peer 
Sync Request (2, 5) -------- > 


Peer has the values (2, 4), so it sends 
6 ee a (5, 4) as the Sync Response 


In this example, the newly active member expects to send the next IKE 
message with ID 2. It sends an expected receive value of 5, which is 
higher than the last ID value it has seen from the peer, because it 
believes some incoming messages may have been lost. The peer has 
last sent a message with ID 1, and received one with ID 3, indicating 
that a couple of messages sent by the previously active member had 


not been synchronized into the other member. So the peer’s next 
expected (send, receive) values are (2, 4). The peer replies with 
the maximum of the received and the expected value for both send and 
receive counters: (max(2, 5), max(4, 2)) = (5, 4). 

A.4. Simultaneous Failover 


In the case of simultaneous failover, both sides send their 
synchronization requests simultaneously. The eventual outcome of 
synchronization consists of the higher counter values. This is 
demonstrated in the following figure. 


Standby (Newly Active) Member Peer 
Sync Request (4,4) |  ----- > 
ST eae Sync Request (5,5) 
Sync Response (5,5) ----> 
i I E UEM Sync Response (5,5) 
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